home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Essentials / Technical.Notes / IIGS / TN.IIGS.051 < prev    next >
Encoding:
Text File  |  1990-09-21  |  5.9 KB  |  152 lines  |  [TEXT/pdos]
  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5.  
  6. Apple IIgs
  7. #51:    How to Avoid Running Out of Memory
  8.  
  9. Revised by:    Dave Lyons    September 1990
  10. Written by:    Eric Soldan    January 1989
  11.  
  12. This Technical Note discusses handling nearly-out-of-memory situations when 
  13. working with the IIgs tools.
  14. Changes since January 1989:  Retitled from "Reserving Memory for the Toolbox."  
  15. Noted that many toolbox calls require 16K or 32K of memory to be allocatable 
  16. for reliable operation.
  17. _____________________________________________________________________________
  18.  
  19.  
  20. Introduction
  21.  
  22. Running out of memory is a concern for most every application.  Working with 
  23. the Toolbox makes monitoring this situation a little more difficult since your 
  24. application is not the only one allocating memory.
  25.  
  26. Low-level toolbox functions (for example, QuickDraw II calls) require that a 
  27. 16K block of memory be allocatable, while high-level routines (for example, 
  28. the Window Manager) require that a 32K block of memory be allocatable.  Apple 
  29. does not guarantee that toolbox functions behave reasonably if there is less 
  30. memory available, and the tools are not stress-tested with less than the 
  31. minimum required memory available.
  32.  
  33. Since the toolbox assumes reasonable memory-allocation requests succeed, just 
  34. waiting for an out-of-memory error is not adequate memory management.  To make 
  35. your application work reliably in low-memory situations, you need a method of 
  36. ensuring that the toolbox gets memory when it needs it.  This Note describes 
  37. two approaches.
  38.  
  39.  
  40. How Much Memory Can Be Allocated
  41.  
  42. There's no way to tell how much memory can be allocated without actually 
  43. trying to allocate it.
  44.  
  45. MaxBlock tells you the size of the largest single free block, but this doesn't 
  46. take into account purgeable blocks, compaction, and out-of-memory routines 
  47. (see Apple IIgs Toolbox Reference, volume 3).  FreeMem and RealFreeMem cannot 
  48. tell you how badly fragmented the memory is, and they do not take into account 
  49. out-of-memory routines.
  50.  
  51.  
  52. A Suggested Method
  53.  
  54. A method of checking for a nearly-out-of-memory condition is to have your own 
  55. purgeable handle just for this task.  If the handle has not been purged, then 
  56. you have plenty of memory for the toolbox, and in the worst case, the toolbox 
  57. purges your handle if it needs the RAM.
  58.  
  59. The less often your purgeable handle gets purged, the better performance you 
  60. get in nearly-out-of-memory situations.  Therefore, you should arrange for 
  61. other purgeable memory, not necessarily belonging to your application, to be 
  62. purged before your handle.  For example, you want dormant applications to be 
  63. purged, rather than having your handle get repeatedly purged and reallocated.  
  64. So the purge level of this handle should be one.
  65.  
  66. The check to see if a handle has been purged is very fast.  If it has been 
  67. purged, you have to try to reallocate it.  Reallocating a handle is not a fast 
  68. process, so the fewer times the handle is purged, the faster the check is and 
  69. the better your performance.  Unless you are in a nearly-out-of-memory 
  70. situation, the handle should not be purged at all, and you should have 
  71. virtually no overhead for this process.
  72.  
  73. This technique can be implemented as follows:
  74.  
  75. appStart
  76. ;
  77. ; Somewhere at start, create a purgeable handle of size N,
  78. ; called "loMemHndl", purge level 1.
  79. ;
  80.                  rts
  81.  
  82. ******************
  83. ;
  84. ; Here's an example of checking for nearly-out-of-memory:
  85. ;
  86.                  jsr    preCheckLoMem
  87.                  bcc    goForIt
  88.                  bcs    HandleError        ;Handle errors appropriately.
  89. goForIt          (_ToolboxCall[s])         ;Make as many as needed.
  90. ;
  91. ; Here you can make your toolbox calls.  Since you prechecked
  92. ; for nearly-out-of-memory conditions, you should have no memory
  93. ; errors at this point.
  94. ;
  95. ; You could also check after calls, as shown here:
  96. ;
  97.                  (_ToolboxCall)
  98.                  jsr    checkLoMem         ;Call this to see if low.
  99.                  bcc    noError
  100.                  bcs    HandleError        ;Take care of errors.
  101.  
  102. noError          jsr    lifeIsGood
  103.                  .
  104.                  .
  105.                  .
  106.                  rts
  107.  
  108.  
  109. ******************
  110. ;
  111. ; Here are some sample routines to check for the nearly-out-of-
  112. ; memory condition.
  113. ;
  114. checkLoMem       bcs    retErr
  115. preCheckLoMem    lda    [loMemHndl]
  116.                  ldy    #2
  117.                  ora    [loMemHndl],y
  118.                  beq    gotPurged
  119.                  lda    #0
  120.                  clc
  121.                  rts
  122. gotPurged        (Try reallocating it into loMemHndl, purge level 1.)
  123.                  (If you can't, you will get a $0201 error.  You may wish to 
  124.                   return the $201 error, or you may wish to change it into
  125.                   your own error code.)
  126. ;
  127. retErr           rts                       ;This is a single exit point
  128.                                            ;whether errors were present
  129.                                            ;or not.
  130.  
  131. You can determine the size of this purgeable handle, but like determining what 
  132. size stack is adequate for an application, there is no single "right" answer.  
  133. There are different considerations for size of the purgeable handle for each 
  134. application, and these may change during the development process.  Use your 
  135. best judgement, keeping in mind that high-level toolbox routines require a 32K 
  136. block.
  137.  
  138.  
  139. An Alternative
  140.  
  141. For better control over when your handle is purged or disposed, you can write 
  142. an out-of-memory routine as described in the Memory Manager chapter of Apple 
  143. IIgs Toolbox Reference, volume 3.  Out-of-memory routines have the opportunity 
  144. to free up memory before or after the Memory Manager attempts to purge 
  145. purgeable handles, and this manual contains a sample of such a routine.
  146.  
  147.  
  148. Further Reference:
  149. _____________________________________________________________________________
  150.   o  Apple IIgs Toolbox Reference, Volumes 1-3
  151.  
  152.